This tiny example shows why interface class inheritance is cool, and how it is used for "bindings".
The project itself doesn't do anything very interesting: you move a scrollbar or a slider (the "sender"), and its value is communicated to and displayed by either a staticText or to a progressBar (the "recipient"), depending on what choice you've made with two sets of radioButtons.
It sounds pretty simple.
But now think about this from a programming point of view. Without interface classes, the scrollbar or slider would have to know exactly who it was talking to in order to communicate its value. A staticText wants a string, and displays it in its Text property. A progressBar wants a number, and displays it in its Value property.
Also, the scrollbar or slider would have to alter a property of the staticText or progressBar, directly. That seems unpleasantly counter to proper object orientation.
That's the advantage of interface classes. The radioButtons are able to "bind" the scrollBar to the staticText, or the scrollBar to the progressBar, or the slider to the staticText, or the slider to the progressBar, and yet none of these objects needs to know the class of any of the other objects.
Furthermore, instead of the sender changing the recipient's property, the recipient inquires of the sender and changes its own property, which is much more object-oriented.
